home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000015_roddick@unisa.edu.au _Sat Oct 31 09:36:46 1992.msg < prev    next >
Internet Message Format  |  1996-01-31  |  3KB
  1. Received: from Levels.UniSA.Edu.Au (roll.Levels.UniSA.EDU.AU) by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA18032; Fri, 30 Oct 1992 16:09:02 MST
  3. Received: from [130.220.236.42] (Mac.LV-MG2.Levels.UniSA.Edu.Au) by
  4.  Levels.UniSA.Edu.Au (PMDF #2428 ) id <01GQLE4L2F6899EY63@Levels.UniSA.Edu.Au>;
  5.  Sat, 31 Oct 1992 09:37:21 +1030
  6. Date: 31 Oct 1992 09:36:46 +0930
  7. From: roddick@unisa.edu.au (John Roddick)
  8. Subject: Re: Temporal-database concepts and terms
  9. Sender: majfr@adder.levels.unisa.edu.au
  10. To: tsql@cs.arizona.edu
  11. Message-Id: <01GQLE4LNL4Y99EY63@Levels.UniSA.Edu.Au>
  12. X-Envelope-To: tsql@cs.arizona.edu
  13. Content-Transfer-Encoding: 7BIT
  14.  
  15. The following two entries are prompted by an apparent confusion in the
  16. literature regarding the two terms Schema Evolution and Schema Versioning. 
  17. In many papers they are used interchangeably which I believe is wrong as
  18. the definitions demonstrate.
  19.  
  20. \subsection{Schema Evolution}
  21.  
  22. \entry{Definition}         
  23. A database supporting schema evolution permits the modification of the
  24. database schema without loss of extant data.
  25.  
  26. \entry{Alternative Names}   
  27. Schema Versioning is a separate but allied concept which allow user
  28. definition of schema changes - see definition.  
  29.  
  30. Some thought was also given to using the terms 'data evolution' and 'schema
  31. evolution' but these were rejected due to the latter's usage in the
  32. literature.
  33.  
  34. \entry{Discussion}
  35. i.   In it's simplest sense, schema evolution does not imply full
  36. historical support for the schema; only the ability to change the schema
  37. definition without loss of data.  In practice, retention of past
  38. definitions will probably be appropriate.  In contrast, Schema Versioning,
  39. even in its simplest form, requires that a history of changes be maintained
  40. to enable the retention of past schema definitions.
  41.  
  42. ii.  The significant difference between evolution and versioning is the
  43. ability for users to identify quiet points in the definition and 'label'
  44. the definition in force at that time for later reference.  Schema Evolution
  45. does not require the ability to version data except in so far as each
  46. changed schema can be considered a new version.
  47.  
  48. iii. Schema changes will not necessarily result in a new version. 
  49. Typically schema changes will be of a finer grain than the definable
  50. versions.
  51.  
  52. iv.  Versions will tend to be labelled by some user-defined method whereas
  53. schema evolution changes are referred to more often by the (transaction)
  54. time of change.
  55.  
  56.  
  57.  
  58. \subsection{Schema Versioning}
  59.  
  60. \entry{Definition}         
  61. Schema Versioning is accommodated when a database system allows the viewing
  62. of all data, both retrospectively and prospectively, through user definable
  63. version interfaces.
  64.  
  65. \entry{Alternative Names}   
  66. Schema Evolution is an allied concept.
  67.  
  68. \entry{Discussion}
  69. See discussion under Schema Evolution
  70. John.
  71. -------------------------------------------+--------------------------
  72. John Roddick                               | Ph.  (08) 302 3643
  73. School of Computer and Information Science | Int. +61 8 302 3463
  74. University of South Australia              | Fax  (08) 302 3381
  75. The Levels                                 | Int. +61 8 302 3381
  76. SOUTH AUSTRALIA     5095                   | Net. roddick@unisa.edu.au
  77.